Skip to content

Conversation

@schodet
Copy link
Contributor

@schodet schodet commented Sep 8, 2025

Stop the "running" animation on the first drawing to the screen, and clear screen when the user program exits.

Refs: pybricks/support#2154

First proposal to get the ball rolling.

@coveralls
Copy link

coveralls commented Sep 8, 2025

Coverage Status

coverage: 58.736% (-0.01%) from 58.75%
when pulling 5ac584c on schodet:stop-anim-on-draw
into 9759e90 on pybricks:master.

Stop the "running" animation on the first drawing to the screen, and
clear screen when the user program exits.

Refs: pybricks/support#2154
@laurensvalk
Copy link
Member

Thank you! I've been working on some refactoring lately that is somewhat related.

We have a similar aspect for the animation of the hub light on Technic/City/Move Hub. This is actually an animation that runs in user space, much like any other user animation, so doesn't really belong in pbio/sys. I've been refactoring it to move it away from there.

The light matrix animation in SPIKE is somewhat similar, and by extension, a display animation for EV3 might be as well.

I'll merge the code for the button light animation shortly, and then I'll have a look as to how it applies for the display. Once we do that, we are free to make other animations if we want to, not restricted to the 5x5 grid.

@schodet
Copy link
Contributor Author

schodet commented Sep 9, 2025

I had the same feeling about pbio/sys not being the right place.

The idea is to have the animation and screen control at the same place that the user program start/stop handling.

Depending on your refactoring work landing time, would you mind merging anyway so it solves my problem until this is moved elsewhere?

@laurensvalk
Copy link
Member

In the case of the LEDs, there is the complication that system error codes may override user light. I could see that possibly applying to the light matrix and display as well, but I don't suppose we need to make it that generic unless we really need it.

So indeed the simpler way would be to have full user control while the user program is active, and have a possible animation start in user space. When the program ends, the UI regains control.

@laurensvalk
Copy link
Member

Would you mind merging anyway so it solves my problem until this is moved elsewhere?

Yes, we can do that 😄

@laurensvalk
Copy link
Member

At closer look, it looks like #382 is already heading in the right direction. There is a dedicated place that starts and stops the user animation for both the user light and light matrix. It is called when the program begins, rather than triggered by events about the program starting. Would it make sense to revisit and add your PR on top of that?

@laurensvalk
Copy link
Member

And simplifying further... Considering that we only have the light matrix display so that we can have a UI for now, we can avoid this problem entirely by just not starting the animation in the first place and clearing the display when the program starts and ends. I've added a commit to #382.

Tested by drawing on the screen from the user program. It is erased when the program ends, and a clean screen appears when the program begins. If that works well enough for you, we could close this PR.

@schodet
Copy link
Contributor Author

schodet commented Sep 9, 2025

OK for me.

@schodet schodet closed this Sep 9, 2025
@schodet schodet deleted the stop-anim-on-draw branch September 12, 2025 08:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants